home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c / 360 < prev    next >
Text File  |  1996-08-06  |  4KB  |  101 lines
  1. Newsgroups: comp.std.c
  2. Path: nntp.coast.net!torn!sq!msb
  3. From: msb@sq.com (Mark Brader)
  4. Subject: Re: Is a diagnostic required?
  5. Message-ID: <1996Feb23.090526.7591@sq.com>
  6. Organization: SoftQuad Inc., Toronto, Canada
  7. References: <danpop.824999740@rscernix>
  8. Date: Fri, 23 Feb 1996 09:05:26 GMT
  9.  
  10. Dan Pop (danpop@mail.cern.ch) writes:
  11. > Does the following code require a diagnostic?
  12. > 
  13. >     foo() { }
  14. >     main() { foo(3); } > 
  15. > I was always convinced that there is no difference between foo() and
  16. > foo(void) in the _definition_ of the function foo ... Yet, all the
  17. > compilers I tried accepted this code without complaint and complained
  18. > when 'void' was introduced in the definition of foo.
  19.  
  20. The language of the standard is fuzzy here, but I believe that it is
  21. clearly intended for the diagnostic to be mandatory when the "void" is
  22. present, and optional otherwise (the behavior being undefined).
  23.  
  24. An excerpt from the Constraints of section 6.3.2.2/3.3.2.2 (emphasis added):
  25.  
  26. #  If the expression that denotes the called function has a type that
  27. #  INCLUDES a prototype, the number of arguments shall agree with the
  28. #  number of parameters.
  29.  
  30. As this is a Constraint, a violation requires a diagnostic.  But from the
  31. Semantics of the same section (emphasis added):
  32.  
  33. #  If the expression that denotes the called function has a type that
  34. #  DOES NOT include a prototype ...  If the number of arguments does
  35. #  not agree with the number of parameters, the behavior is undefined.
  36.  
  37. Thus no diagnostic is required if this is the only violation.  I must
  38. say it's rather disgusting that none of the compilers Dan tried was smart
  39. and helpful enough to produce the diagnostic anyway -- it would after
  40. all be easy enough for them to do so in this case.  (Cancel that remark
  41. if they were all compilers intended to be used with lint for checking.)
  42.  
  43. Now, "prototype" is defined in 6.1.2.1/3.1.2.1:
  44.  
  45. #  A "function prototype" is a declaration of a function that declares
  46. #  the types of its parameters.
  47.  
  48. And in case there was any doubt, both 6.5/3.5 and 6.7.1/3.7.1 make it
  49. clear that a definition is a kind of declaration.  I won't bother to
  50. quote them here.
  51.  
  52.  
  53. These passages are sloppy for the following reasons:
  54.  
  55. 1. "Function prototype" is defined, but the term used elsewhere in the
  56.    standard is just "prototype".
  57.  
  58. 2. It is defined as a syntactic construct, not something that might be
  59.    "included" in a type.
  60.  
  61. 3. If a function has no parameters, it is not possible to distinguish
  62.    whether they are declared or not.
  63.  
  64. 4. The old-style function definition
  65.  
  66.     void fu (x,y) short x,y; { }
  67.  
  68.    is a declaration that declares the types of the function's parameters,
  69.    but if this was deemed to be a prototype, existing code would be broken.
  70.  
  71.    The way to resolve both points 3 and 4 is to relate the term "prototype"
  72.    more directly to the new-style syntax, which it is obviously intended
  73.    to denote.  In section 6.5.4.3/3.5.4.3, where function declarators and
  74.    their semantics are actually defined, the term is avoided altogether and
  75.    "parameter type list" is used instead.  "Prototype" probably should have
  76.    been defined in these terms.  Note that void is a type, so foo(void)
  77.    would be a valid function declarator with a prototype, while foo()
  78.    would unambiguously not have a prototype.  There is no syntactic
  79.    ambiguity since a parameter type list is not allowed to be empty.
  80.  
  81. 5. The punctuation of the quoted passage from 6.3.2.2/3.3.2.2 Semantics
  82.    is ambiguous: it isn't clear whether the first If-clause quoted is
  83.    meant to govern the second one, which is in a different sentence.
  84.    More precisely, the punctuation suggests that it does not, but in
  85.    other places in the standard similarly punctuated, it would.  In
  86.    this case, however, material later in the paragraph suggests that
  87.    the last-quoted If-clause is not meant to be within the scope of the
  88.    other one.
  89.  
  90.    Fortunately, this parsing ambiguity makes no difference in this case;
  91.    the overall effect is the same with either parsing, no matter whether
  92.    a prototype is used or not.
  93.  
  94. If you take the intended readings as being what I said, then you end up
  95. with the conclusion I gave above.  If not, you probably don't.
  96. -- 
  97. Mark Brader, msb@sq.com       "I'm not a lawyer, but I'm pedantic and
  98. SoftQuad Inc., Toronto         that's just as good."      -- D Gary Grady
  99.  
  100. My text in this article is in the public domain.
  101.